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MDMS  SOFTWARE  DESIGN  DOCUMENT 

1.  SCOPE 

1.1.  Identification 

Computer  Software  Configuration  Item  (CSCl):  Master  Oceanographic 

Obsemtion  Data  Set  (MO(X>S)  Data  Management  Sj^m  (MDMS) 

Version:  1.0 

Rdease  Date:  22  August  1994 

Orntract  No:  NAS  13-330,  Order  No.  53 

Contra^on  Mississq^  Stale  Univmity 
Cento' for  Air  Sea  Technology 
J.  H.  Coibin,  Director 
Building  1103,  Room  233 
Stomis  Space  Center,  MS  39S29-60(X) 

Telephone:  (601)  688-2561 
Facsimile:  (601)  688-710C 

Project  Manager:  Ms.  Cheryl  Cesatio 

Mississqipi  State  University 

Center  for  Air  Sea  Tedmology,  Stennis  Space  Cotter,  Mississii^ 
39529-6000.  (MSU  Proposal  No.  93-3-467) 

Telephone:  (601)  688-7141 
FacsimUe:  (601)  688-7100 


1.2  Overview 

The  MOODS  Data  Management  System  (MDMS)  provides  access  to  the  Master 
Oceanogn^c  Observation  Data  So  (MCX)DS)  which  is  maintained  by  the  Naval  Oceanogrt^c 
Office  (NAVOCEANO).  The  MDMS  incorporates  database  technology  in  providing  seamless 
access  to  parameter  (temperature,  salinity,  soundspeed)  vs.  depth  observatitHi^  profile  data.  The 
MDMS  is  an  interactive  software  aj^dtcaticMi  with  a  grafdiical  usmr  interface  (GUI)  that  sur^xrrts 
user  control  of  MDMS  fiincdmial  capabUities. 

U  Document  Overview 

The  purpose  of  tfiis  document  is  to  define  and  describe  the  stnumal  framework  and  logical 
deagn  of  the  software  ctxiqxxients/uiiits  whidi  are  integroed  into  the  major  computer  software 
oxi^iratkm  item  (CSCI)  idoitified  as  MDMS,  Version  1.0.  The  preliminary  design  is  based  on 
fUnctkmal  ^pecificatkms  and  reqi^ments  idmitified  in  (he  govmning  Stateumtt  of  Wok  primed 
by  the  Na^  Oceanographic  Office  (NAVOCEANO)  and  distribute  as  a  request  for  prcf)osal  by 
tte  National  Ararcmautics  and  Space  Administration  (NASA).  The  ccmtent  and  format  of  this 
document  ate  qecified  by  Department  of  Defense  (DOD)-STD  2167A  (2.1). 

Appmidix  A  contains  a  glossary  of  terms  used  within  this  document  Appoidix  B  is  a 
listing  of  acronyms  used  witiiin  titis  document  The  MDMS  relatitmal  database  specification  is 
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caMamed  in  Appendix  C.  Appendix  D  contains  functional  and  design  iequirran»its  f(»-tfae  MDMS 
relational  database  mana^ment  system  (RDBMS).  Refa  to  Appendix  E  ftn-  a  description  of  tiie 
MDMS  developo^t  enviionmeaL  Appradix  F  ctmtains  listings  of  relevant  source  code  stnictures. 
Appendix  O  ptovides  intormation  ab(Mt  tire  MDMS  ccnfiguration  fite. 

2  RI31»ENCED  DOCUMENTS 

Note:  The  sections)  <x  subsecti(m(s)  of  tiiis  document  wherein  a  reference  is  cited  appears 
as  parmtiretical  information  tidlowing  each  document  listed  in  tiiis  section. 

2. 1 .  DOD-STD  2167A  “Defense  System  Software  DeveIopm«it”,  AMSC  No.  N4327, 
29  Feb  88.  (1.3) 

2.2.  Young,  Douglas  A.,  *The  X  Windows  System  Programming  and  Applications  with 
Xt,  OSF/Motif  Editi<m”,  Prentice  Hail,  Englewood  Cliffs,  NJ,  1990.  (3.1. 1.1) 

2.3.  Jurlrevics,  Andrew,  “Database  Design  Document  for  the  Naval  Environmental 
Operationid  Nowcast  System,  Versiem  3.S“,  Naval  Oceanographic  and  Atmosfdieric 
Research  Laboratory,  Mtmterey,  CA,  1  June  1992.  (3.1)(3.1.1.4) 

2.4.  Documentation  (Series)  for  tire  Empress  Relatimial  Database  Management  System, 
Version  6.X,  Vcl.  Al-Dl,  Empress  Software  hicorporated,  Gieenbelt,  MD,  1993. 
(3.1.1.4) 

2.5.  Users  Manual  and  Referrace  Guides  for  UNIRAS  ag/X  Toolmaster  Grafdiics 
Extmisions  library,  Versiem  6v3b,  UNIRAS,  Incorporated,  Overland  Park,  KS, 
1993.  (3.1.1.1) 

2.6.  Cofitin,  Stephen,  “UNIX  System  V  Release  4:  ttie  Complete  Reference”,  Osborne 
McGraw-Hill,  New  York,  N  if,  1990.  (Useful  reference  for  broad  overview) 

3  PRELIMINARY  DESIGN 
3.1  CSCI  Overview 

The  Master  Oceanogta{^c  Observation  Data  Set  (MOODS)  Data  Management  System 
(MDMS),  a  stand-akme  system,  is  the  maj^  Computer  Software  Configuration  Item  (CSCI)  to  be 
develop^  by  tiiis  project.  Functicmal  requirements,  as  identified  by  the  sponsor,  were  not  defined 
in  the  ermtext  of  a  modular  aiproach  to  software  development  Thmefore,  tiie  tasks  necessary  to 
fulfill  tiie  functional  lequberhents  have  been  divided  among/assigned  to  the  internal  Computer 
Setitware  Components  {CSC)  for  acconplishnrent  Tire  ti>p-level  (sim^distic)  MDMS  architecture  is 
illustrated  in  Hgure  1. 

Thme  are  tiuee  principle  CSC’s  within  tire  MDMS  structure: 

a.  CSC-1:  Graphical  Urer  Interface  (GUI)  -  incorporates  initialization,  window 
manag^nent,  us^  interface  and  diqday  functionality; 

b.  CSC-2:  Data  Management  Module  (DMM)  -  provides  functional  data 
managemrat  usi^  relational  RDBhffi  technology, 

c.  CS<^3:  Data  Administration  Module  (DAM)  -  incorporates  administrative 
contn^  d  tire  apfdication  and  is  inaccessible  to  tiie  general  user. 
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The  only  access  to  the  MDMS  is  via  the  User-GUI  external  interface  which  supports  1) 
application  initialization,  2)  user  control  of  the  MDMS  using  interactive  techniques,  3) 
lesponse/feedback  to  the  user  in  the  form  of  data  display  (graphical  or  numerical)  and  status 
indicators,  4)  indirect  access  to  data  contained  in  the  MOODS  database,  and  5)  indirect  access  to 
files  and  data  that  are  not  resident  within  the  MOODS  database.  The  DMM  accesses  the  MOODS 
database  and  data/configuration  files  through  its  external  interfaces.  The  Naval  Environmental 
Operational  Nowcast  System  (NEONS)(2.3)  controls  access  to  the  external  MOODS  database  and 
has  been  modified  to  accommodate  specific  storage  and  retrieval  requirements  of  the  MDMS. 

3.1.1  CSCI  Architecture 

Figure  1  illustrates  the  MDMS  top-level  (simplistic)  module  and  its  external  interface 
architecture. 


CSCI:  MDMS 


Figure  1.  Top-level  modular  structure  of  the  MOODS  Data  Management  System  (MDMS).  The 
\&MS  is  tile  Computer  Software  Configuration  Item  (CSCI).  There  are  tiuee  Computer  Software 
Components  (CSC). 

3.1.1.1  CSC-1:  Graphical  User  Interface  (GUI).  The  MDMS  GUI  supports  and 
manages  the  link  betw^n  the  user  and  the  MDMS.  Through  the  GUI,  the  user  exercises  all 
available  MDMS  ccmtrol  optiom .  The  MDMS  provides  displays  to  tiie  user  for  interpretaticHi  and 
interactive  response.  The  GUI  is  integrated  witii  the  following  non-developmental  software: 

a.  X-Windows  (proprietary):  Manages  all  controls  and  display  windows.  The 
X-Windows  client/server  model  supports  remote  user  access  to  the  MDMS  using  network  protocol 
via  the  UNIX  operating  system.  X-Windows  operation  is  explained  in  detail  in  reference  2.2. 

b.  Open  Software  Foundation  (OSF)  Motif  Widget  Toolkit  (proprietary): 
Provides  a  widely  accepted  standard  inventory  of  window  compcaients  (widgets)  that  is  pleasing  to 
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the  eye  and  easy  to  intnpret  For  iiuKe  information  on  |m>gramming  using  the  Motif  Widget 
Toolkit,  see  lefmnce  2.2. 

c.  UNUtAS  Toolmaster  (proprietary):  Handles  gn^hical  representation  and 
visualization  of  data  displays.  See  reference  2  J  for  detailed  information  concerning  ag/X 
Toolmaster. 

FuncticHially,  die  GUI: 

a.  Pnf(»ms  application  initializatiai  and  ev^tmcMiitoring  functions; 

b.  Exercises  direct,  cratralized  control  over  die  DMM  and  DAM; 

c.  Mtmiters  activities  of  the  DAM  and  the  DMM  and  its  database/filemtmfaces; 

d.  Intercepts,  interprets  and  routes  uso*  interactive  commands; 

e.  Serves  as  die  ag^tfOT  communications  between  die  DMM  and  the  DAM; 

f .  Provides  status  information  and  fee^ck  to  the  user; 

g.  Provides  the  windowing  environment  for  visualization  of  data,  display  of  control 
elemants  and  intercepting  us^  interactive  commands; 

h .  Receives  and  interprets  user  input  via  the  keybo^  or  mouse  pointing  device; 

i.  Incorporates  visualization  routines  to  plot  data  displays  for  viewing  by  the  usmr. 

3.1. 1.2  CSC-2:  Data  Management  Module  (DMM).  The  MDMS  DMM  is  primarily 
tasked  with  managing  access  to  and  communications  widi  the  external  M(X)DS  RDBMS  via  its 
NEONS  (modifted)  interface.  The  DMM  coirununicates  widi  tee  GUI  to  pass  informetion  from  the 
database  and  external  files.  It  communicates  with  the  DAM  to  enable  MOODS  Database 
Administrator  (MDB  A)  control  over  application  confrguration.  When  a  data  request  is  received 
from  die  GUI,  the  DMM  notifies  NEONS  to  retrieve  the  data  from  the  MOODS  database.  When 
tee  data  has  been  received,  tee  DMM  informs  the  GUI  and  passes  its  location  iu  memory.  The 
DMM  also  receives  data  management  instructions  from  both  the  GUI  (user)  and  tee  DAM 
(MDBA).  hi  turn,  dirough  NEONS,tee  DMM  translates  teese  instructi<ms  Into  Structured  (^ery 
Language  (SQL)  commands  to  the  RDBMS.  The  DMM  is  also  responsible  for  allocating  tee 
internal  memory  space  for  data  retrieved  frran  tee  database  or  data  destined  for  database  ingestion. 

3.1. 1.3  CSC-3:  Data  Administration  Module  (DAM).  The  MDMS  DAM  is 
respcmsible  for  managing  MDBA  fiinctimis  widiin  tee  MDMS.  MDBA  functions  ate  not  accessible 
to  tee  general  user.  These  fimctitHis  include  importing  data  into  tee  database  and  updating  of 
MDMS  plication  tables  (classificatkxi  codes,  date  source  codes,  instrumrat  types)  which  are  teen 
made  available  for  user  interactimi  witiim  tee  (}UI. 

3.1.1.4  NEONS  (modifled).  The  MOODS  database  is  accessed  via  a  modified  version  of 
NEONS,  which  performs  high  level  management  of  tee  M(X)DS  database.  The  specific 
modifications  to  NEONS  for  tee  MDMS  allow  use  of  additional  keys  to  support  optimal  database 
qumy  and  date  retrieval  from  tee  MOODS  primary  database  tables  (which  contain  tee  actual  date). 
The  M(X)DS  database  is  a  relational  database.  NEONS  includes  bote  tee  structural  model  for  tee 
database  and  the  applications  prograiruner  interface  (library  routines)  required  to  access  tec 
MOODS  database  t^les  using  tee  Ammican  Naticmal  Stands^  Institute  (ANSI)  standard  SQL. 
NEONS  was  developed  by  tee  Naval  Research  Laboratory,  Monterey,  CA.  A  detailed  descriptirai 
of  NEONS  is  available  in  the  NEONS  design  documrat  (2.3).  NEONS  employs  the  proprietary 
Empress  (2.4)  relational  data  management  system  (RDBMS)  for  low-level  management  of  tee 
M(XH>S  database. 
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3.1.1^  USER-GUl  (USER/CSC-1)  External  Interface.  The  USER-GUI  interface 
provides  user  control  of  the  MDMS.  The  interface  is  impleniented  by  means  of  a  pointing  device 
(mouse)  \^ik:h  is  employed  by  the  user  to  pass  signal  instructions  (events)  to  the  application,  and 
the  Imyboard  ^ch  is  u^  to  pass  text  inf(»tnati(xi  to  die  application. 

3.1.1.6  GUI-DMM  (CSC-l/CSC-2)  Internal  Interface.  The  GUI-DMM  internal 
interface  consists  of  all  ^Uittes  for  communication  between  the  GUI  and  die  DMM.  The  GUI- 
DMM  interface  is  an  abstiactimi  employed  to  group  diose  actions  \(hk:h  pass  information  betweoi 
the  two  mothiles.  Actual  communication  between  the  GUI  and  the  DMM  is  usually  accomplished 
directly  by  dte  GUI  and  DMM  timctions  involved. 

3.1.1.7  GUI-DAM  (CSC-l/CSC-3)  Internal  Interface.  The  GUI-DAM  internal 
interface  ctmsists  of  all  facilities  for  communication  between  the  GUI  and  the  DAM.  The  GUI- 
DAM  intoface  embodies  die  same  timctionality  and  abstract  character  as  the  GUI-DMM  interface. 

3.1.1.8  DMM-DAM  (CSC-2/CSC-3)  Internal  Interface.  There  are  only  two  instances 
where  die  DMM  and  DAM  communicate  directly  with  each  other.  These  instances  are  discussed  in 
Section  4.2.2.  Odiermse,  the  DMM  and  DAM  communicate  indirectly  via  the  GUI. 

3.1.1.9  DMM-NEONS  External  Interface.  DMM-NEONS  external  interface  consists 
of  all  NEONS  library  functions  that  ate  integrated  within  the  MDMS.  These  functions  goierate 
SQL  commands  to  die  Empress  RDBMS,  returning  status  indicators  and  performing  two-way  data 
transferal,  when  successfully  executed. 

3.1.1.10  DMM’FILES  External  Interface.  The  DMM-FILES  external  interface  consists 
of  all  fimctimis  within  the  DMM  which  result  in  direct  reading  from  or  writing  to  files  within  die 
operating  system’s  file  management  facility. 

3.1.2  System  States  and  Modes 

The  MDMS  is  an  interactive  software  s^plication.  The  application  is  always  in  an  event- 
driven  state.  As  with  all  event-driven  software  applications,  the  MDMS  may  assume  either  of  two 
execution  states  (modes):  (1)  pixxtessing  mode  and  (2)  rest  (idle)  mode.  The  MDMS  default  state  is 
the  rest  mode.  Vi^en  not  processing  data  in  response  to  user  input,  the  application  automatically 
reverts  to  the  rest  mode  (evrat  mcxiitoring  loop)  and  awaits  the  next  user  command  or  input 

3.1.3  Memory  and  Processing  Time  Allocation 

The  intmnctive,  evoit-dtiven  nature  of  die  MDMS  precludes  a  quantitative  description  of 
memory  allocation  and  processing  time  among  MDMS  CSC’s.  It  is  therefore  considered  sufficirat 
to  state  that  the  MDMS  responds  to  user-graerated  commands  by  allocating  memory,  swap  space 
and  processor  time  within  the  limitations  imposed  by  available  memory,  process  loading  and 
l^nx  operating  system  constraints. 

3.2  CSCI  Design  Description 

The  CSCI  (MDidS)  consists  of  three  CSC  modules  with  functionality  as  described  above. 
Functional  requiremrats  for  the  CSCI,  as  stated  by  the  spcxisor,  could  not  always  be  accomplished 
wholly  and  completely  within  a  single  CSC.  For  instance,  the  final  display  of  ^file  data  r^uires 
tee  cooperative  contribution  of  bote  tee  GUI  and  tee  DMM  modules.  The  remainder  of  this  section 
identifies  MDMS  requirem^ts,  by  CSC,  and  describes  the  software  design  employed  to  achieve 
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tfie  leq^ked  fiinctioiiality .  The  CSCI  incorpcHaies  all  MDMS  functioDal  recmiiemakts  (MFR)  md 
design  lequixenimts  (I^R)  as  pcesented  in  Secti<m  7  of  this  document  In  addition,  die  ^CI 
achieves  qiecific  desi^  lequiiements  which  ate  not  accomplished  by  any  CSC  (MDRl  thiou^ 
MDR4). 

3JL1  Grnpliical  User  Interfiice  (GUI)  (CSC-1) 

CSC-1  is  lespcmsible  for  ^viding  die  visual  display  link  betweoi  the  user  and  the  MDMS 
main  interactive  di^lay.  The  design  for  die  MDMS  main  interactive  display  window  is  illustrated 
in  Figure  2.  The  GUI  is  die  idtimate  destination  of  all  visibte  computadcmal  results  achieved  by  the 
CSCI  and  its  subordinate  CSC’s.  The  DMM  (CSC>2)  performs  data  management  chmies  for  the 
GUI  and  DAM.  Tlie  DAM  (CSC-3)  performs  MDBA  applications  control  and  maintenance 
functions.  The  GUI  and  its  subordinate  components  achieve  die  following  specific  functional  and 
(^ign  requiremraits,  either  wholly  or  in  conceit  widi  other  CSC’s  (see  Section  7): 

MDMS  Ftinctional  Requirements  (MFR) 

MFRl,  MFR2,  MFR3.  MFR4,  MFR5.  MFR6,  MFR7,  MFR8,  MFR9.  MFRIO 
MFRll,  MFR12.  MFR13,  MFR14,  MFR15,  MFR17,  MFR18.  MFR19,  MFR  20, 
MFR21,  MFR22,  MFR23,  MFR24,  MFR26,  MFR30,  MFR32,  MFR33. 

MDMS  Design  Requirements  (MDR) 

Mim8 
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mocimbtm^HicoFFice^sA 


kiiV.^.  t 


ii«= 


Data  Selection 


Selection  Status 


^  Minimum 


Classification 


1010010  Unclassined;  u 
1100010  Unclassified 
10001000  delete  class 


Latitude 


30.000000 


Longitude 


118XJ20000 


CiassiflcatioTi 


1100010 


1100010 


Instrument 


Month* 


Month 


December 


December 


Z  Mechanic^  Oathytf 
5  nev/ 

10  Som'e  unknown  eieci 
ill  Expendable badiytbt 


January 

February 

March 

Apill 


Parameters 


Cruise  ID 


instrument  Type 


Source  Code 


Source  Code 


2  FNOC  message  dab 
0  NOOC  SDil  -  through 
e  rNOCXBTlnSPOTfr 
7  NODC  STD  d«t  high  r 


Loading  Date 


198Z1211 


!■  Maximum 


35.BG0000 


143.050000 


196912302130 


130696 


13921211 


Figure  2.  Illustration  of  the  MDMS  Graphical  User  Interface  (GUI)  (CSC-1)  display  screen.  The 
GUI  is  the  origin  and  final  destination  for  all  interactive  coordination  between  the  user  and  user- 
controllable  processes  resident  in  the  Data  Management  Module  (DMM)  (CSC-2),  the  Data 
Administration  Module  (DAM)  (CSC-3)  and  their  intcmal/cxtemal  interfaces. 

3.2.2  Data  Management  Module  (DMM)  (CSC-2) 

ITic  Data  Mtmagcmcnt  Module  (DMM)  (CSC-2)  controls  the  acquisition  and  di.stribution  of 
data  within  the  MDMS  CSCI.  The  user  has  no  direct  interaction  with  the  DMM.  The  DMM  and  its 
sub-level  components  achieve  the  following  specific  functional  and  design  requirements,  cither 
wholly  or  in  concert  with  other  CSC’s  (sec  Section  7): 

MDMS  Functional  Requirements  (MFR) 

MFR13,  MFR14,  MFR15,  MFR17,  MFR18,  MFRI9,  MFR2(),  MFR21,  MFR22, 
MFR23,  MFR24,  MFR27,  MFR28,  MFR29,  MFR30,  and  MFR31. 

MDMS  Design  Requirements  (MDR) 

Best  Available  Copy 
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MDR5,  MDR6,  and  MDR7. 

3.2.3  Data  Administration  Module  (DAM)  (CSC-3) 

The  DAM  provides  tools  that  enable  application  maintenance  by  the  MDB A.  There  are  no 
specific  design  requirements  for  the  DAM.  The  DAM  and  its  sub-level  components  achieve  the 
following  specific  functional  requirements,  either  wholly  or  in  concert  widi  other  CSC’s  (see 
Section  7): 

MDMS  Functional  Requirements  (MFR) 

MFR12,  MFR13,  and  MFR15. 

4  DETAILED  DESIGN 

Figure  3  illustrates  the  functional  cormectivity  within  the  MDMS  and  forms  the  basis  for  the 
detailed  design  of  the  MDMS  CSCI.  The  preUminary  design  (see  Sectiori  3)  provides  a  broad 
overview  of  the  framework  and  functional  ^sign  of  the  MDMS  (^CI  and  its  three  major  CSC  s 
[Graphical  User  Interface  (GUI),  Data  Management  Module  (DMM)  and  Data  Administration 
Module  (DIM)].  In  this  section,  each  CSC  and  its  computer  software  units  (CSU)  will  be 
describ^  in  greater  detail. 
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USER 


GUI/CSC-1 


DMM/CSC-2  ^^DAM/CS^ 


Figure  3.  MDMS  detail  design  and  connectivity. 


4.1  CSC-1  -  The  MDMS  Graphical  User  Interface  (GUI) 

The  MDMS  GUI  (CSC-1)  embodies  all  facilities  for  user  interaction.  Functions  performed 
by  the  GUI  include: 

a.  Application  initialization; 

b.  Event  monitoring; 

c.  Window  management; 

d.  Communicating  with  the  user  and  the  Data  Management  and  Data  Administration 

modules; 

e.  Creation  and  display  of  data  plots  from  data  received  from  the  DAM; 

f.  Processing  and  interpretation  of  user  commands  via  the  pointing  device  (mouse)  and  the 

keyboard; 

g.  Providing  visual  feedback  in  respcxise  to  user  input  and  internal  messages; 
g.  Management  of  the  user  “Help”  facility; 

g.  Application  shutdown. 
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4.1.1  Initialiaitioii 


The  Initializaticxi  CSU  receives  control  when  die  opoating  system  releases  oxitiol  to  ttie 
applicatkMi.  Functkms  petformed  by  die  Initialization  CSU  include: 

a.  Parsing  and  inteipeting  any  command  line  arguments  that  identify  the  default 

cc^guratitm  mename  by  die  functimi  parscArgO: 

b.  Establidimg  a  ccmection  to  ^  X  server,  initializing  die  Intrinsics  layer  and  obtaining  a 

To(i.evelSbell  widget  by  the  function  XtlnitiaKzeQ; 

c.  Obtaining  pointers  to  Ae  Xlib  Display  and  Screen  structures  using  die  functicms 

XtDisplayO  and  XtScreenO; 

d.  Read^  die  MOODS  configuration  file; 

e.  Opoiing  die  database  using  die  db  stiutO  function; 

f.  Creation  and  display  of  the  MDM^^4^  Window,  its  window  tree  and  data  structures 

including  drfault  range  values  obtained  from  the  ctxifiguratimi  file  via  the  function 
CreateTreeO: 

g.  Initializing  internal  MOODS  data  structures  via  function  InitMoodsStructO; 

h.  Establishing  user  access  privileges. 

i.  Executing  the  XtMainLoopO  event  monitoring  function  which  dispatches  all 

subs^ent  evmts  to  re^stered  event  handle  and/w  callback  fimctitms. 

4.1.1.1  MDMS  Initializatioii  Specification/Coiistraints 

The  design  criteria  for  die  MDMS  Initialization  CSU  are  listed  in  Section  7,  ‘Requirements 
Traceability”.  This  CSU  is  constrained  by  the  following  software-specific  requirements: 

a.  X-Windows  and  OSF  Motif  must  be  installed  and  accessible; 

b.  The  Empress  RDBMS  must  be  installed  and  accessible; 

c.  UNIRAS  ag/X  Toolmaster  must  be  installed  and  accessible; 

d.  NEONS  must  be  instaUed  and  accessible; 

e.  A  MOCX>S  database  must  be  available. 

4.1.1.2  MDMS  Initialization  Design 

Tbe  MDMS  Initializatioi  design  adopts  the  standard  X-Windows/OSF  Motif  protocol  The 
XtMainLoopO  function  ultimately  assumes  control  after  all  initialization  procedures  have  been 
accompMied.  including  display  of  the  Main  Window.  XtMainLoopO  implements  an  infinite 
event-monitoring  loop  which  executes  (dispatches  messages  to)  register^  evoit  handling  and/or 
callback  functions  in  respcmse  to  the  occunoice  of  evoits. 

4.1.2  MDMS  Main  Window 

Tire  Main  Window  CSU  is  illustrated  in  Figure  2.  It  is  subdivided  into  five  areas: 

a.  The  title  area; 

b.  The  menubar  iiihich  allows  access  to  us^-selectable  n^u  items  via  pull^wn  mraus; 

c.  The  “Data  Selection”  area  which  provides  access  to  most  configuration  parameters 

required  to  idoitify  MOODS  dtbisets  and/or  subsets; 


cL  Hie  “Selecticxi  Status”  area  which  displays  range  limits  (minimum  and  maximum)  fen: 
parameters  defined  widiin  die  'Tlata  Sdectkm”  area  and  for  die  ‘‘Select:  Regkm”  and 
‘^Select:  Time”  menu  items; 

e.  The  “Remark”  textbox  which  communicates  important  messages,  such  as  errms,  to  die 
user. 

The  Main  Window  is  created  and  di^layed  during  apfdicatioo  initialization.  All  MDMS  features  are 
initiated  via  the  Main  Window  or  its  subordinate  windows  (pop-ups,  texdioxes,  listboxes,  etc.) 
vdiich  i^ipear  in  re^ionse  to  user  interactioo  with  Mam  Window  sdectioQ  features. 

4.1.2.1  MDMS  Main  Window  SpecificationAI!onstraints 

The  design  criteria  for  die  MDMS  Main  Window  CSU  are  listed  in  Section  7, 
“Requirements Traceability”.  This  CSU  is  constrainedly  die  following  lequirmnents; 

a.  The  X-seiver  must  be  (^lened  and  available  for  din^y;^ 

b.  UNlEtASag^Tocdinasteriniist  be  active  for  hancuing  graphics  functionality; 

c.  The  Enmtess  RDBMS  must  be  active  and  die  MOODiS  database  must  be  open  .  and 

available  for  reading. 

4.1.2.2  MDMS  Main  Window  Design  f 

The  MDMS  Main  Window  design  en^loys  die  X,  Motif,  NEONS,  and  UNIRAS  ag/X 
Toolmaster  libraries.  The  design  is  implemented  du^g  initialization  by  the  function 
CreateTreeO*  i  I 

4.1.3  GUI  Fonctionality  | 

Aftn  die  MDMS  Main  Window  has  been  dii^yed,  die  usv  is  £tee  to  interact  widi  it  using 
die  mouse  and  keyboard.  The  GUI  translates  all  mouse  and  keybc^  evmits  into  calls  to  event 
lumdlors  and/or  callback  functions.  If  the  event  requiro  retrieval/ingestion  of  data  firom/to  die 
M(X)DS  database,  the  GUI  adls  upcm  a  functitm  within  die  DMM.  If  the  event  requires  MDBA 
intervention  or  a  security  check,  tte  GUI  cs^  upon  a  functkxi  widiin  the  DAM. 

4.13.1  The  Menubar 

The  menubar  ccmsists  of  five  pull  down  menu  headers  (Select,  MDBA,  Products, 
Util),  each  of  which  offers  two  or  more  subordinate  menu  items,  plus  the  Help  buttmi  which 
provides  access  to  die  cm-line  hdlp  facility.  Whoi  clicked,  a  mmiu  hen^  is  programmed  to  di^lay 
its  subordinate  menu  items,  ^ch  themselves  may  be  selected  by  clicking.  The  reactimi  of  the 
a]^cation  to  selectirm  of  a  menu  item  depoids  upcxi  die  functionafity  of  die  particular  moiu  item. 
Selections  made  via  the  menubar  provide  access  to  all  qkions  diat  are  not  direcdy  associated  with 
e^diliriiing  die  criteria  for  data  retrieval. 

4.1.3.1.1  Select:  Region 

Whoi  die  “Region”  menu  item  is  clicked,  the  function  r^^ouButtmiPressO  is  executed 
and  the  window  illustrated  in  Hgure  4  is  disfdayed.  This  window  offers  three  (^ons  for  selecting 
die  boundaries  of  a  ^c^rtqibical  region.  The  “R^on  list”  contains  a  listing  of  user-selectable  ^ 
defined  regions,  ^en  a  pre-dei^ed  region  is  selected  fiom  the  “Region  List”,  the  region 
boundary  is  ^splayed  widiin  die  imq)  window  as  a  dashed  rectangle,  and,  die  label^  textboxes 
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within  die  ‘^Region  Cooidinates’*  wi^t  are  modified  to  hold  the  latitude  and  longitude  cooidinate 
limits  of  die  re^on.  Whoi  a  regitm  is  selected  by  dragging  the  mouse  cursor  across  an  area  of  die 
nu^  display,  the  "‘Re^rm  Coor^ates”  textboxes  are  modified  to  hold  the  latitude  and  longitude 
coordinates  of  the  region.  Finally,  a  region  may  be  defined  by  selecting  individual  texdioxes  within 
the  **Region  Coordinates”  widget  and  entering  replacement  values  from  the  Iceyboard.  If  greater 
resolution  is  required,  the  ‘*Zoom”  button  located  below  the  map  will  produce  a  pc^up  window 
containing  an  enlarged  image  of  the  regicm  defined  on  the  map.  The  “File”  pulldown  menu 
provides  menu  items  to  exit  the  display  and  to  reset  the  coordinates  to  their  original  values. 
Selecting  the  '‘Exit”  menu  item  destroys  die  window  and  sends  die  latitude  and  Icmgitude  boundary 
coordinates  to  die  “Selection  Status”  board  within  the  MDMS  Main  Winde  r. 


Figure  4.  The  MDMS  Re^on  Selectimi  Window.  This  window  appears  in  lespcHise  to  selecting 
die  “Region”  vasm  item  via  the  “Select”  pulldown  menu. 


4.U.1.2  Select:  Time 


When  the  'Time”  menu  item  is  clicked,  die  functimi  timeButtonPressO  is  executed  and 
the  'Time  Selection”  window  illustrated  in  Figure  5  is  displayed.  This  wintkiw  offers  options  for 
selecting  the  time  constraints  for  a  MOODS  datalme  que^.  If  the  “Start”  button  is  activated,  the 
adjacent  row  of  text  widgets  is  also  activated  for  input  of  minimum  date/time  values.  If  the  “End” 
button  is  activate^  the  adjacent  text  widgets  are  activated  for  ratry  of  maximum  date/time  values. 
Date  ratries  may  also  be  changed  using  the  up  or  down  arrow  switch  buttons  to  the  right  of  the 
vertically  arrayed  “YEAR”,  “MONTH”,  “DAY”,  and  “JULIAN”  textboxes.  These  arrow  switches 
are  manipulate  by  clicking.  Qianges  made  using  the  arrow  switches  are  applied  to  the  activated 
“Start”  or  “End”  row  of  textboxes.  Clicking  the  “Exit”  button  closes  die  ‘Time  Selection”  window 
and  transfers  die  values  to  die  maximum  and  minimum  Date/Time  textboxes  within  the  “Selection 
Status”  b(Mrd  of  die  MDMS  Main  Window. 
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Figuie  5.  The  MDMS  Time  Sdecdoa  Window.  This  window  appears  in  response  to  selecting  die 
‘Time**  inenu  item  via  the  *^lect”  pulldown  inaiiL 

4.13.1.3  Select:  Exit 

Whra  the  "Exit**  menu  itmn  is  clicked,  the  hmctioa  edtProgramO  is  executed.  Clicking 
the  "Exit**  menu-item  closes  die  MDMS  main  display  screen  and  returns  die  user  to  the  system 
command  line  pronqit 

4.13.1.4  MDBA:Import  (MDBA  Only) 

During  initializatitxi,  die  fiinctitm  creatdlbaToolsO  determines  if  die  usot  is  die  MDBA. 
The  source  c^. . . 

if  (lOsDbn))  {  XtSetArg  (wargs[n],  XmNsensitive,  False); 

sets  die  Tmport**  menu  item’s  sensitivity  argument  to  "False**,  dierel^  disallowing  data  import  by 
users  other  man  me  MDBA.  Whm  me  MDBA  selects  me  "ImporT  mrau  item  from  die  ‘MDBA** 
pull-down  menu,  the  function  createlmportExportDialogO  is  executed  wim  me 
miportexport->tyy  variable  set  to  IMPORT  and  die  "Input  File**  pop-up  window  (Figure  6)  is 
di^yed.  The  "mputFUe**  pqp-up  window  contains  a  texdxix  for  entry  of  the  file  name  (induding 
pi^  if  needed)  and  "(Be**  and  "Exit**  buttems.  To  be  ingested,  me  file  contrats  must  be  in  the 
“MOODS  Admin”  format.  Clicking  the  “Ok”  button  executes  the  function 
importexportOkSelectO  which,  in  turn,  calls  me  DMM  function  readlngest_flle0  to  read 
die  file  and  in^st  ^  mita  into  the  database.  Clicking  the  "Exit”  button  executes  me  function 
laomorlexportlhdtSelectO  which  destro:^  me  "Impc^  File”  pop-up  window  and  rdums  to  die 
iWlfafaiLoopO  fiim:tion  without  petfonning  any  data  ingestirai  opwui(»s. 


Figure  6.  MTO  A  FUename  E&tiy  I^ak%  Window  for  Im^ 

4.1^.1.5  MDBA:Exp<Ht 

Tire  MCX)OS  expoft  fireility  is  availabk  re  afi  uren  posressiiig  a  level  of  accere  apotopnate 
for  the  data  to  be  exported.  When  the  user  selects  the  ‘*&cporr  menu  item  from  the  ‘^IDBA** 
pull-down  menu*  two  additiooal  menu  items  appear,  *%)mort  Admin**  and  *^port  IDEAS**.  If 
^Eiqxxt  Adtaiin**  Is  seeled,  foe  function  erentelnywtExpoftPinlotO  is  executed  wifo  foe 
iBiMrtaxport->type  variable  set  to  EXPORT  and  foe  •‘Bj^on  File**  pop-up  window  (Figure 
7si)  is  delayed,  u  **Export  IDEAS**  is  selected,  createImsortExporU>ialogO  ia  executed 
w^  the  tamortwmort->^npe  vaiiaUe  set  re  EXPORT__IDEAS  and  foe  *^p(M  IDEAS  Hie** 
pt^p  s^dow  OE^ne  7.b)  is  disj^yed.  Both  export  pop-up  windows  amtain  a  texfoox  for 
entry  of  foe  eaqxxtffle  name  (inching  pafo,  if  needed),  and  and ‘*Exir  buttons,  (kicking 

foe  ^Ok**  button  executes  foe  function  impoitexportOkSelectO  which,  in  turn,  calls  foe  Dh^ 
function  cniortDMbilFilcO  which  writes  tire  dafo  to  tire  nanred  file  in  eitirer  MOODS  "Admin** 
or  MOODS  "lEQBAS**  format  The  format  depends  upon  foe  value  of  importezport-Mype 
(EXPORT  or  EXPORT  IDEAS).  Oicl^g  foe  "Exit**  button  executes  foe  function 
iiiiportexportExltSelec^*^ch  destroys  the  file  export  pop-up  window  and  returns  to  the 
mfaiidxKipO  fimetion  without  performing  any  data  export  functions. 


Hgure  7  JL  MDBA  Hlename  Entry  Dialog  Window  for  hKXX)S  "Admin**  Export 


Figure  7.b.  MDB A  Filename  Entry  Dialog  Windows  for  MOODS  ‘TCeAS”  Format 

4.1J.1.6  MDBA:Update  Table  (MDBA  Only) 

The  "Update  TaUe**  menu  item  is  a  tool  fm  use  of  tiie  MDBA  only.  During  initializatioa, 
tire  function  oeateDbaToo^  determines  if  the  user  is  the  MDBA.  The  source  code... 

if  (!(isDba))  {  XtSetArg  (wargs[n],  XmNsensitive,  False);} 
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sets  the  “Update  TaUe”  mmu  item’s  soisitivity  argummt  to  “False”,  dier^  disallowing  data  tabte 
updates  by  users  odier  dian  the  MDBA.  When  selected,  the  “Update  Table”  moiu  itm  produces  a 
submenu  widi  three  selectable  menu  items:  “Updt^  Instrument”;  Update  Source”;  and  “Update 
ClassiAcation”.  The  GUI  functions  respectively  responsible  foi  these  options  are 
npdateClassiflaitionO,  updatelnstnimeiitO.  tmd  sonrceUpdateO.  producing  the  pop-up 
tmdows  shown  in  Hgu^  8,a,  8.b.  and  8.c.  Each  of  diese  functions  executes  tte  DAM  functitm 
cbangeTableO  h>  **ADD”,  “DELETE”,  or  “UPDATE”  the  omtents  of  the  specified  qualitative 
code.  changeTableO,  in  turn,  calls  the  DMM  function  moodsUpdaU^ltvInfoO  which 
updates  the  MOODS  dabdnse  qualitative  infonnation  table  and  makes  the  tq^priate  ent^  in  the 
MOODS  Log. 


Figure  8.a.  MDBA  Update  Instrument  Pop-up  Window. 


Figure  8.b.  MDBA  Update  Source  Pop-up  Window. 
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Figure  8.C.  MDBA  Update  Classification  Pop-up  Window. 

4.1.3.1.7  PRODUCTS:  Distribution 

When  the  user  clicks  the  ‘Distribution”  nienu  item  from  the  “Products”  pulldown  menu,  the 
GUI  frmction  selectDistribution  ()  is  execute  selectDistributionO  produces  the  MOODS 
“Distribution  Plot”  pop-up  window  shown  in  Figure  9,  which  allows  user  definition  of  data 
distribution  plotting  options  (“Distribution”,  “Histogram”  or  “Accumulation”).  This  window  also 
offers  choices  for  latitude/longitude  and  coastline  resolution,  display  to  screen  or  printer,  and 
(optionally)  the  inclusion  of  a  title.  Relevant  GUI  callback  functions  and  their  roles  in  generating 
MDMS  Products.'Distributicm  displays  are  as  follows; 

pIotTypeTogglePressO  -  upon  selection  (click)  of  the  “Distributitm”  toggle  button. 
histTypeTo^ePressO  -upon  selection  (click)  of  the  “Histogram”  toggle  button. 
acclTypeTo^ePr^O  -  upon  selection  (click)  of  the  “Accumulation”  to^le  button. 
devTo^ePressO  -  upon  user  selection  of  display  choice  (“Screen”  or  “Printer”). 
chooseSKmO,  chooseSKmO,  or  choose20KM()  -  upon  selection  of  the  type  of 
coastline  to  be  drawn  in  conjunction  with  the  plot. 
exitDistributionO  -  upon  selection  (click)  of  the  “Exit”  pushbutton. 
enterLatD^O  -  supports  text  entry  of  latitude  (east/west)  square  size. 
enterLonDegO  -  supports  text  entry  of  longitu(te  (north/south)  square  size. 
enterTitleO  -  supports  text  entry  of  an  optional  plot  title. 

executePlotDistnbutionO  -  upon  selection  (click)  of  the  “Ok”  button  and  calls  the 
appropriate  routine  based  on  the  plot  t^  selected. 
exposeDistributionO  -  exposes  the  “Distribution”  plot  drawing  area  window  and  its 
contents. 

destroyDialogO  -  destroys  the  pop-up  window  upon  exiting. 

exposeHistogramO  -  exposes  the  “Histogram”  plot  drawing  area  window  and  its 
contents. 

exposeAcclO  -  exposes  the  “Accumulation”  plot  drawing  area  and  its  contents. 

These  functions  will,  in  turn,  call  a  variety  of  associated  functions  within  the  DMM  to  obtain  the 
ai^wopriate  data  from  the  database.  The  data  query  is  constructed  from  information  contained  in  the 
“Selection  Status”  board  (Section  4.1. 3.3).  Figures  lO.a  and  lO.b  are  example 
distribution/accumulation  and  histogram  plots. 
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Figure  9.  Distiibuticm  Plot  Definition  Window. 


Figure  10.a.  Profile  Distribution/Accumulation  Plot  Window. 
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Figure  lO.b.  Histogram  Plot  of  Profile  Distribution. 

4.1.3.1.8  PRODUCTS:  Depth  Vs.  Farm 

When  the  “Depth  Vs  Parm”  menu  item  is  clicked,  the  function  selectParmvsDepthO  is 
executed.  selectParmvsDepthO  produces  an  adjacent  pulldown  submenu  for  choosing  Depth 
vs.  Temperature,  Depth  vs.  Salinity;  or  Depth  vs.  Sound  Speed.  Selection  of  either  submenu  item 
produces  the  appropriate  depth  vs.  parm  defmition  window  for  that  option.  Figure  1 1  illustrates 
the  depth  vs.  temperature  parm  de^ition  window  (The  depth  vs.  sanity  and  depth  vs.  sound 
speed  defmition  windows  are  labeled  “Salinity”  and  “Sound  Speed”,  respectively;  otherwise,  they 
are  identical  in  appearance  and  functionality  to  the  depth  vs.  temperature  window).  Relevant  GUI 
functions  and  their  roles  in  generating  MDMS  ProductsrDepth  vs.  Farm  displays  are  as  follows; 

sndSpdSelectO  -  when  Sound  Speed  parameter  has  been  chosen  as  the  composite 
plot. 

tempSelectO  -  when  Temperature  parameter  has  been  chosen  as  the  composite  plot.. 
salinitySelectO  -  when  Salinity  parameter  has  been  chosen  as  the  composite  plot. 
tempvsSalinitySelectO  -  when  Temp  vs  Salinity  has  been  chosen  as  the  composite 
plot. 

countSizeEditO  -  supports  text  entry  of  maximum  number  of  MOODS  profiles. 
minXEditO  -  supports  text  entry  of  minimum  value  for  X-axis. 
maxXEditO  -  supports  text  entry  of  maximum  value  for  X-axis. 
minYEditO  -  supports  text  entry  of  minimum  value  for  Y-axis. 
maxYEditO  -  supports  text  entiy  of  maximum  value  for  Y-axis. 
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titkEditO  -  supp(»ts  text  entiy  of  a  gn^  title. 
ezitPBrmVdkpdiO  -  me  ‘*Exit**  pi^buttoa  has  been  selected. 
compDevTcmptePressO  -  whoi  me  device  selecti(»  (inintei/scieen)  toggle  button  has 
beeodklDed.  j 

expoeeOm^poBiteO  -  to  expose  me  composite  drawing  area.  | 

When  me  *‘Ok”  buttmi  is  pressed,  me  function  exeeuteCompositePlotO  calls  me  DMM 
function  conmMmMoodsReadO  which  retrieves  appropriate  data  from  me  MOODS  database. 
execnteCompositeFliMtO  mmi  calls  me  GUI  functioo  drawCompositeQ,  which  draws  and 
exposes  me  composite  param^^  vs.  dej^  window  and  its  contmits.  Figure  12  illustrates  me 
‘Tenoqpeiature  vs.  Depm”  conqx^dte  plot  Ollier  cmnposite  pltXs  are  similar. 


Figure  1 1.  Depm  vs.  Temperature  Defmition  Window. 
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Figure  12.  Depth  vs.  Temperature  Plot  Example. 

4.1.3.1.9  PRODUCTS:  Print  Header 

The  function  selectPrintHeader()  creates  the  dialog  pop-up  window,  Figure  13,  in 
response  to  selection  of  the  “Print  Header”  menu  item  from  the  “Products”  pulldown  menu. 
selectPrintHeaderQ  calls  the  function  outputFormatDialogO  to  perform  the  actual  creation 
of  the  dialog  pop-up  window.  outputFormatDialogO  registers  callback  functions 
fileTogglePressO,  screenTogglePress()  and  printTogglePressO  which  process  user 
selection  of  an  output  device.  fileTogglePressO  calls  the  function  filenameDialogO  to  create 
a  secondary  pop-up  dialog  window  for  retrieval  of  a  user-entered  filename  by  the  callback  function 
readFilenameO.  Selection  of  the  “Exit”  button  is  processed  by  the  callback  function 
exitPrintHeaderi)-  The  callback  function  executePrintHeaderO  is  registered  (indirectly,  via 
the  outputFormatDialogO  argument  procO)  to  process  selection  of  the  “OK”  button. 
executePrintHeaderO  calls  the  DMM  function  commonMoodsReadO  to  retrieve  the 
appropriate  data  from  the  database  and  the  DMM  function  moodsLogMesgEntryO  to  make  the 
required  log  entry.  The  screen,  file  or  printer  output  from  the  “Print  Header”  menu  item  is  in 
MOODS  ADMIN  format.  Screen  output  is  display^  by  making  a  system  call  invoking  the  UNDC 
vi  text  editor. 
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Figure  13.  Print  Header  Ou^  Selectkn  Window. 

4.1.3.1.10  PRODUCTS:  Print  Log  (MDBA  Only) 

The  ‘‘Print  Log”  mmu  item  leqxmds  (xily  to  the  MDBA.  The  ‘Trint  Log”  dialog  window. 
Figure  14,  is  inoduced  by  the  callback  function  selectPrintLogO  ^ich  calls  die  function 
pmtLogLayontO  to  construct  the  necessary  window  components  and  register  the  necessary 
callback  functions  as  follows: 

readFunctionO  -  to  capture  the  MDMS  transactimi  function  type(s)  selected  from  the 
scrollable  “Functions”  list 

readUserNameO  -  to  ci^iture  the  name  of  the  user  of  interest  to  the  MDBA. 
readMinPateQ- to  capture  the  minimum  date  as  altered  in  die  “Min  Date”  field. 
readMadlateO  -  d)  capture  the  maximum  date  as  entered  in  the  “Max  Date”  field. 
toJileTogg^hdhressO  -  to  process  MDBA  selecticm  of  die  ‘Tile”  ou^t  option. 
execateLogjllataO  -  to  process  MDBA  selectimi  of  the  “OK”  button. 
reseOiOgStructO  -  d)  process  MDBA  selecdmi  of  die  ‘Reset”  button. 
qoitPrinitLogO  -  to  process  MDBA  selectitm  of  the  “Exit”  buttmi. 

lileTogglePressO  calls  the  function  filenameDialogO  to  create  a  secondary  p^up  dialog 
window  for  retrieval  of  a  user-entered  filename  by  die  caUback  function  readlnlenameO. 
mrecuteLogDatiiO  calls  toe  DMM  functitm  moodsLogDataQ  to  retrieve  log  entries  toat  meet 
toe  critmia  establitoed  by  MDBA  oitries  in  toe  “Print  Log”  dialog  window  and  output  toe  data  to 
screen,  printer  <x  file  (see  Figure  IS). 


Figure  14.  Print  Log  Definition  Window. 


Figure  15.  Print  Log  Screen  Output  Example. 


4.1.3.1.11  PRODUCTS:  Page  Summary 

The  “Page  Summary”  pop-up  dialog  menu  item,  Fi^ijie  16,  is  created  by  the  callback 
function  selectPageSummaryO.  selectPageSummaryO  presents  three  page  summary 
output  options  (screen,  printer  or  Me).  Actual  creation  of  the  dialog  window  is  accon^)lished  by 
the  function  outputFormatDialogO  which  registers  callback  functions  fileTogglePressO, 
screenTogglePressO  and  printTo^lePressO  to  process  user  selection  of  an  output  device. 
fileTogglePressO  calls  the  function  filenameDialogO  to  create  a  secondary  pop-up  dialog 
window  for  retrieval  of  a  user-entered  filename  by  the  callback  function  readFilenameO.  The 
function  executePageSummaryO  is  passed  as  an  argument  to  outputFormatDialogO  by 
selectPageSummaryO.  executePageSummaryO  processes  retrieval  of  the  appropriate  data 
from  the  database  via  DMM  function  commouHeaderReadO  and  outputs  the  page  summary  to 
file,  screen  or  printer.  outputFormatDialogO  reuses  the  callback  function  exitPrintHeaderO 
to  process  selection  of  the  “Exit”  button.  Figure  17  is  an  example  of  “Page  Summary”  screen 
output. 


Figure  16.  Page  Summary  Definition  Window. 
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Figure  17.  Page  Summary  Screen  Output  Example. 


4.1.3.1.12  UTIL:  Read  Defaults  File 

The  function  createUtilO  registers  the  callback  function  selectReadFileO  to  create  the 
“Read  Defaults  File”  pop-up  dialog  window  shown  in  Figure  18.  This  dialog  window  is  a  standard 
Motif  widget  created  by  the  function  XmCreateFileSelectionDialog().  File/directory  selection 
from  the  scrollable  listings,  entry  of  a  path/file  into  the  “Selection”  textbox  and  selection  of  the 
“Directory”  button  are  handled  internally  by  the  widget.  The  callback  function 
flleNameAcceptCBO  responds  when  the  “Load”  button  is  selected  by  calling  the  function 
executeReadDefaultsFile().  executeReadDefaultsFile()  resets  MDMS  de^ult  values  to 
those  contained  in  the  newly  loaded  defaults  file  via  the  functions  readMoodsDefaultsO, 
clearMoodsStructO,  clearMoodsSelectionQ  and  $etMoodsSelection(). 
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Figaae  18.  Util  Read  Defaults  Window. 


4.1.3.1.13  UTDL:  Write  Defaults  File 

The  function  createUtilO  legistera  die  callback  function  selectWriteFileO  to  create  the 
'Write  Defaults  File”  pop-up  dialog  window  shown  in  Figure  19.  selectWriteFileO.  in  turn 
calls  the  function  create^^ameDialogO  iritich  registers  the  additional  callback  functions 
exltDefiaultsFileO  and  execoteWriteDeraidtsFileO  to  handle  the  '^xit”  and  'K)K”  buttons, 
and  die  callback  ftmction  readFUeNameO  to  capture  die  output  filename  entered  by  the  user. 
executeWiiteDefault^eO  arilects  cuirmt  ^ues  for  all  default  variable  membos  and  vmtes  diem 
to  a  text  file. 


Figure  19.  Util  Read  Defaults  Window. 


4.1.3.1.14  HELP 

The  function  createMenubarOptionsO  registers  the  callback  function 
nioodsO|»iHd^  to  create  pop>up  dialog  windows  in  respcmse  to  selection  of  the  “Help”  moiu 
header.  moodsC^uHelpO.  in  turn,  registers  the  callback  fimctimi  moodsOpuHelpOkO  to 
process  selection  of  the  “OK”  button  associamd  with  each  “Help”  pop-up  dialog  window. 
moodsOpiiH^pO  registers  a  recursive  callback  to  itself  to  process  a  senes  of  help  pop-up  dialog 
windows.  Help  text  is  contained  in  die  include  file  moodsOpuHe^Ji. 


I 
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4.13.2  The  Data  Selection  Screen 

The  ‘^Data  Selection”  pcvticm  of  the  “Main  Window”  occupies  most  of  the  left  side  of  the 
MDMS  Main  Window  display  screen  (see  Figure  2).  The  function  dataSelAndDisplayO  is 
called  by  Ae  fimctimi  CreateTreeQ  to  create  both  Ae  “Data  Selection”  and  “Selection  Status” 
windows.  dataSdAndlNsplayO  relies  upon  the  fimctimi  dataSelectDesignO  to  construct  the 
“Data  Selectitm”  window  and  its  suite  of  interacti^  widgets.  dataSelectD^ignO  registers  the 
following  callback  fimcti<ms  to  process  user  selecticm  and  entry  of  key  MDMS  database  qumy 
parameters,  all  of  which  must  be  defined  pricH*  to  any  database  qu^: 

readCmiseldO  -  to  read  the  minimum  or  maximum  cruise-ID  entered  into  the  “Cruise 
ID”  textbox. 

readMonthO  -  to  capture  the  minimum  or  maximum  month  selected  from  the  scrollable 
“Months”  listbox. 

readNumParmO  -  to  process  the  minimum  or  maximum  number  of  parameters  selected 
via  die  sliding  “Number  or  Parameters”  scale  widget 

readLoadDateO  -  to  read  the  minimum  or  maximum  loading  date  entered  into  the  “Load 
Date”  textbox. 

readSourceO*  -  to  capture  the  minimum  or  maximum  data  source  code  selected  from  the 
scrollable  “Source”  listbox. 

readClassO*  -  to  oqiture  the  minimum  or  maximum  classification  code  selected  from  the 
scrollable  “Qassification”  listbox. 

readlnstO*  -  to  capture  the  minimum  or  maximum  instrument  code  selected  from  the 
scrollable  ‘Tnstrument”  listbox. 

*Note:  dataSelectDesignO  employs  the  function  fiUlistO  to  construct  the  codes  listed 

in  the  “Source”,  “Glassification”  and  “Instrument”  listboxes. 

The  statement... 

if  (moods_struct->query_val->selection_type  ==  MINIMUM) 

determines  if  die  value  retrieved  by  the  callback  functions  re[nesrats  a  minimum  or  maximum  value 
for  each  parameter.  moods_struct->query  val->selection_type  is  set  by  the  callback 
functions  minTogglePressO  and  maxTogglePressf)  which  are  registered  by 
seleciDisplayDesignO,  the  function  which  is  ultimately  responsible  for  creating  the  “Selection 
Status”  window  loca^  to  the  right  of  the  ‘T)ata  Selection”  window.  Maximum  and  minimum 
values  for  the  key  parameters  are  placed  in  the  structure  moods_struct  where  they  may  be 
accessed  by  other  \&>MS  functions. 

4.1.3.3  The  Selection  Status  Screen 

The  ‘"Selection  Status”  portion  of  the  “Main  Window”  occupies  most  of  die  right  side  of  the 
MDMS  Main  Window  display  screen  (see  Figure  2).  The  fimction  dataSelAndDisplayO  is 
called  by  the  function  CreateTree()  to  create  both  Ae  “Selection  Status”  and  “Data  Selection” 
windows.  dataSelAndDisplayO  rclies  upon  the  function  selectDisplayDesignO  to  construct 
the  “Selection  Status”  window  and  its  suite  of  interactive  widgets.  selectDisplayDesignO 
registers  the  following  callback  functions  to  retrieve  and  display  minimum  and  maximum  values 
for  the  key  parameters  defined  widiin  die  “I^ta  Selecti<xi”  window: 
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miiiToffliePrcssO  -  to  data  setection  mode  to  minimum  in  response  to  clicking  the 
‘T^finimum**  button. 

maxToggltfressO  -  to  set  data  selection  mode  to  maximum  in  response  to  clicking  the 
‘^Maximum”  toggle  button. 

readMinnmeO  -  to  retrieve  the  minimum  time  from  the  moods^struct  stnicture. 
readMaxThneO  -  to  retrieve  the  maximum  time  from  the  mood^struct  structure. 
readMinlxM^  -  to  retrieve  die  minimum  longitude  from  the  moodsjstruct  structure. 
readMaxLonO '  to  retrieve  the  maximum  Imigitude  from  the  moodsjstruct  structure. 
readMinLiatO  -  to  retrieve  the  minimum  latitude  from  the  iiioods_struct  structure. 
readMaxLatO  -  to  retrieve  the  maximum  latitude  from  the  moodsjstru^  structure. 

The  non-callback  fiincticni  getMontliNameO  is  invdced  to  retrieve  the  minimum  or  maximum 
mondi  value  from  the  moods  struct  structure.  The  remaining  maximum  and  minimum  parameter 
values  are  directly  retrieved  from  the  moodsjstruct  structure  and  inserted  into  their  text  widgets 
by  the  function  selectDisplayDesign(). 

4.1.3.4  Remarks 

llie  ‘‘Remarks”  label  button  and  its  accompanying  texdx>x  are  created  and  displayed  by  the 
function  CreateTree().  Messages  are  printed  in  the  “Remarks”  textbox  by  the  function 
printmesgO  and  removed  by  the  function  clearmesgO. 

4^  CSC-2  •  The  MDMS  Data  Maiuigement  Module  (DMM) 

Visible  functionality  of  the  MDMS  is  the  responsibility  of  the  GUI.  The  DMM  responds  to 
internal  requests  from  the  GUI,  the  DAM  or  other  DMM  functions.  A  request  may  require  data 
retrieval  from  the  MOODS  database.  It  may  require  creation  of  a  new  process  or  application  of  an 
algorithm  on  the  data  after  it  is  retrieved  from  the  database.  The  DMM  may  be  called  uptm  to  read 
MOODS  data  fiom  an  import  file  and  ingest  it  into  die  MOODS  database.  Effectively,  the  user  is 
insulated  from  the  functionality  of  the  DMM,  seeing  only  the  results  which  are  displayed  by  the 
GUI.  Any  data  proc^sing  chores  performed  by  the  DMM  are  associated  with  the  need  to  1) 
provide  data  in  specified  formats  to  the  GUI  an^or  DAM,  or  2)  ingest/retrieve  data  to/ffom  the 
suf^ior^g  MOODS  database.  The  CSU-level  design  of  the  DMM  is  embodied  in  those  ftmctions 
v^ch  interact  widi  the  GUI,  DAM  and  the  supporting  database. 

4.2.1  DMM  Interaction  with  the  GUI 

With  two  exceptions  (see  Section  4.2.2,  below),  all  communicaticxis  with  die  DMM  and  its 
underlying  database  is  invcdced  by  the  GtJl.  At  the  CSU  level,  DMM  interaction  with  die  GUI  is 
accon^lished  via  the  following  DMM  ftmctions: 

InitMoodsStructO  -  to  allocate  memory  for  the  structure  moods  struct  and  initialize 
values.  Default  data  values  are  obtained  from  the  moods.^efaults  file  by  the 
function  readMoodsDefaults()  and  passed  to  GUI  functions  such  as 
selectDisplayDesignO  which  display  the  values  within  its  “Selection  Status” 
text  widgets.  InitMood^tructO  is  alw  invoked  by 
exportData2FileO  -  called  by  the  GUI  function  importexportOkSelectO  to  query 
retrieve  data  from  database  and  write  it  to  a  file, 
readingest  file()  -  called  by  the  GUI  ftmction  importexportOkSelectO  to  import 
MCX^S  ADMIN  data  into  database  with  latitude,  longitude  and  time  plus  seven 
additional  variables. 
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exccuteCompositePlotO  -  called  by  selectParnivs]>epth()  to  fetch  data  from  die 
databa^  for  use  in  (teiwing  composite  parameter  vs.  depdi  plot 
exeeutdPrintHnderO  -  called  by  out^tFormatDialogO  to  fetch  data  from  the  database 
for  use  by  the  Print  Header  moiu  option. 

executeL4>gDataO  -  called  by  printLogLayout()  to  retrieve  specific  log  entries  from 
the  database  as  defmed  by  the  MDB  A. 

executePageSummaryO  -  called  by  outputFormatDialogO  to  retrieve  header 
infoniiatioa  from  database  for  use  by  die  Page  Suiiiinaiy  inenu  option. 

getObsDataO  -  called  by  distributionDrawO,  exposeDistributionO, 
expt^HistogramO  and  exposeAcclQ  to  read  observation  data  from  database 
for  distributioo,  histc^gram  and  accumulation  plots. 

UtMapFuncsO  -  called  by  distributionDrawO  and  exposeDistributionO  to  read 
geographic  coastline  data  from  database  for  plotting  on  a  registered  grid. 

4^.2  DMM  Interaction  with  the  DAM 

As  indicated  in  Figure  3,  the  DMM  and  DAM  are  not  routinely  required  to  communicate 
direcdy  in  order  to  suf^rt  MDB A-^iecific  actions  relative  to  database  maintenance.  In  most  cases, 
Ae  communication  is  accomplished  indirectly;  i.e.,  the  GUI  serves  as  the  messenger  between  die 
DAM  and  the  DMM.  The  following  DMM  functirxis  are  exceptions  in  that  they  do  communicate 
direcdy  with  die  DAM: 

moodsUpdateQltvInfoO  -  called  by  the  DAM  function  changeTableQ  to  update  the 
MOODS  database  qualitative  information  table  and  make  the  appropriate  entries  in 
die  MOODS  Ix^  table. 

moods_brws_2()  -  called  by  the  DAM  function  chk_clas_acc()  to  compare  access 
privile^  of  user  with  selected  classification  codei^ger 

4,2.3  DMM  Interaction  with  the  MOODS  Database 

DMM  fimctions  that  interact  widi  the  MOODS  database  and  dieir  purpose  are  as  follows: 

conunonHeaderReadO  -  to  read  header  information  from  the  database. 

Ilt7_rd0  -  to  read  lit  records  from  the  database. 
lltiT opnQ  -  to  open  the  MOODS  database. 

moodsUpdateQltvInfoO  -  to  update  the  MOODS  database  qualitative  information  table 
and  nudtes  the  appropriate  ratry  in  die  MOODS  Log. 

Ilt7_wr0  -  to  write  a  pnmary  MOODS  profile  data  record  to  the  database. 
lltiT  wr  asO  -  to  write  an  associative  record  to  the  MOODS  database  for  an  ingested 
"  dataset 

43  CSC-3  -  The  MDMS  Data  Administration  Module  (DAM) 

The  purpose  of  the  DAM  is  to  suppcxt  1)  MOODS  Database  AdministratOT  (MpBA)  control 
of  die  MDMS  and  2)  to  exclude  user  access  to  unauthorized  data.  User  access  critmia  can  (xily  be 
established  by  the  MDBA,  which  emphasizes  the  critical  security  responsibilities  of  die  MDBA. 
The  DAM  interacts  directly  with  the  GUI  in  support  of  database  and  software  maintenance 
requirements.  Aside  horn  the  two  excepticm  noted  in  Section  4.2.2,  dieie  is  no  direct  link  between 
die  DAM  and  die  DMM  Inst^ul,  interaction  betwera  the  DAM  and  die  DMM  is  accomplished  via 
die  GUI. 
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43.1  DAM  IMenctkm  wltA  tke  GUI 


At  ttie  CSU  leveU  tbe  ftdlowing  DAM  functioos  interact  with  the  GUI  to  peifonn  the  tasks 

gefUlogiiiO '  called  by  mniiiO  to  obtain  vatt  identification  of  the  cuimit  process. 
gefDbaO  -  ctdled  by  rntrinO  to  identify  the  database  creator. 

checkAecessO  -  called  by  importexportOkSelectO  and  exportData2File()  to 
ensuieverify  user  access  pennisaons  for  file  read/wiite(^)efations. 
changeTableO  >  called  by  insCodeTypeO,  updateCodeTypeO  and 
delCodeTyp^  to  make  necessary  changes  to  MDB A-controUed  parameto'  values 
(classification,  instrument  and  source). 

43,2  DAM  Interaction  with  the  DMM 

(see  Section  4.2.2) 

5  MDMSDATA 

5.1  The  MOODS  Database 

The  MOODS  database  is  described  in  App^idix  C. 

5Jt  MDMS  User  Configuration  Data 

User  configuration  data  is  contained  in  the  moods.defaults  file.  An  example 
nioods.defiiaits  file  can  be  found  in  Appendix  G. 

6  MDMS  DATA  FILES 

The  MDMS  retrieves  data  from  the  MOODS  database,  data  import  files  and  the  user 
cmifigutation  file.  There  ate  no  otfaa  data  requirements  for  the  MDMS. 

7  REQUIREMENTS  TRACEABILITY 

MDMS  functional  requirnmoits  (MFR)  and  design  requiremrots  (MDR)  have  bear  defined 
for  the  MDMS.  MFR/MDR  ret^irements  ate  also  indicated  in  paragra^s  3.2.1, 3.2.2  and  3.2.3 
for  cross-reference  and  traceability.  CSC  responsibility  for  achieving  each  MFR  and  MDR  ate 
indicated  paroidi^cally  in  die  following  descriptions  for  each  MFR  and  MDR. 

MDMS  FUNCTIONAL  REQUIREMENTS  (MFR) 

MFRl:  Operate  in  an  interactive  manner,  Le.,  displays  must  be  interactive.  (GUI) 

MFR2:  Interactively  identify  geqgnqihical  r^on  boundaries.  (GUI) 

MFR3:  hiteractivdy  identify  time  and  date  ran^  (GUI) 

MFR4:  Interactivefy  identify  qiecific  classification  codes  and  ranges  of  same.  (GUI) 

MFR5:  Interactively  identify  specific  cruise  identification  numb^  and  ranges  of  same.  (GUI) 
MFR6:  Interactivdy  identify  specific  data  source  codes  and  ranges  of  same.  (GUI) 

MFR7:  Interactivdy  select  iqiecific  mondi  ctmstraints  and  ranges  of  same.  (GUI) 

MFR8:  hiteractivdy  enter  s^ific  data  loading  dates  and  ranges  of  same.  (GUI) 
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MFR9:  bileractively  bttween  sdectkxi  of  minimum  ukI  maximum  letrieval  parameter 

criteria.  (GUI) 

MFRIQ:  buenctively  select  combinations  of  tmnpoatuie,  salinity  and/or  sound  spoed  for 
processing.  (GUI) 

MFRl  1:  Provide  on-line  help  to  usos.  (GUI) 

MFR12:  lYovide  on-line  addnion,  del^ion  and  update  capability  to  the  MDBA  for  classifcatioD 
codes,  cruise  identiilcation  numbm  and  data  source  cod^  (GUI/DAM) 

MFR13:On-line  data  import  capability  for  MDBA.  (GUI/DMM/DAM) 

MFR14:  On-line  data  expert  capability  for  users.  (GUI/DMM) 

MFR15:  Error  feecfoack  via  message  focility.  (GUI/DMM/DAM) 

MFR16:  CapaUl^  for  nrnlt^  configuratfonAnitialization  files.  (CSCI) 

MFR17;  hiteractivdy  indicate  comidetion  of  retrieval  criteria  devek^anent  and  amunracemrat  of 
data  retrieval  operation  based  on  die  indicated  criteria.  (GUI/DMM) 

MFR18:  Overlay  data  distribution  plots  as  points  on  a  geographic  map  window.  (GUI/DMM) 
MFR19:  Produce  histogram  diqday  of  data  density.  (GUI^MM) 

MFR2Q:  Dis{day  d^>tti  versus  parameter  (tempoature,  salinity,  sound  ^)eed)  plots.  (GUI/DMM) 
MFR21:  Disfday  tnnperattire  versus  salinity  (^}ts.  (GUI/DMM) 

MFR22:  Oitput  header  information  to  prater,  screen  or  file.  (GUI/DMM) 

MFR23:  Mtaintam  log  user  activity  widi  al^ty  to  print  same  to  printer,  sneen 
file.(GUI/DMM) 

MFI^:  Output  statistical  summary  oi  data  retrieved  from  database  wifo  ability  to  print  same  to 
printer,  screoi  or  file.  (GUI/DMM) 

MFR2S:  Provide  MOODS  data  editing  capalMlity.  (independent  of  MDMS) 

MFR26:  System  must  be  able  to  graphcally  {dot  temperature  and  salinity  profiles  onto  a 
geograriiic  grid  or  X- Y  (dot  (GUI) 

MFR27:  Access  to  MOCHDS  ASen  fonnat  (DMM) 

MFR28:  Access  to  MOCXDS  AI^flN  foraat  (DMM) 

MFR29:  Access  to  Coastlines/Shotelines.  (DMM) 

MFR3Q:  Sdectivefy  evaluate  and/or  edit  data.  (GUI/DMM) 

MFR31:  Selectivdy  retain  subsets  of  environmrotal  data  after  evaluation  and/or  editing  procedures 
have  been  performed.  (DMM) 

MFR32:  Interactive  termination  of  a^lication.  (GUI) 

MFR33:  httetactive  reset  of  data  retrieval  (rarameters.  (GUI) 

MDMS  DESIGN  REQUIREMENTS  (MDR) 

MEXIl:  The  MDhK  must  (^renUe  as  a  stand-al(xie  systenL  (C^Q) 

MI%2:  The  MDMS  must  (^)aate  within  die  UNIX  operating  system  oivironiiirait  (CSCI) 

MDR3:  The  MDMS  must  execute  within  die  X-Windows  clim-server  model  (CSC^ 

MDR4:  Window  disidays  must  incoipoiaie  die  0{}ai  Software  Foundation  (OSF)  Mc^  Widget 
Lilnaty.  (CSCI) 

MDRS:  An  indepoidait  relational  database  managemrat  system  (rdbms)  specifically  for  MOODS 
utilization.  (DM^ 

MDR6:  The  Naval  Enviromnaital  Opoational  Nowcast  System  (NEONS)  will  be  incorporated  as 
die  interface  to  the  rdbms.  (DM^ 

MIXI7:  The  MDI^  must  contain  internal  links  to  die  MOODS  rdbms  for  data  im[x>it/expott/ 
retrieval  (DMM) 

MDRS:  The  MDMS  must  incorporate  detection  of  user  privilege  levels  based  on  data  classification 
codes.  (GUI) 
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8  NOTES 


A  glossary  of  terms  is  contained  in  A{^)^dix  A.  A  listing  of  acrcmyms  is  contained  in 
Appendix  B.  Af^ndix  C  is  the  MDMS  RDBMS  Specification.  Appendix  D  lists  MOODS 
RDBMS  fiinctic^  (DBFR)  and  design  (DBDR)  requirements,  ^^^ndix  E  discusses  the  MDMS 
developmoit  environmoiL  Appendix  F  is  a  listing  of  MOODS  structures.  Appendix  G  provides  an 
explanation  of  die  usa  default  file. 
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APPENDIX  A.  GLOSSARY  OF  TERMS 


G>inputer  Software  Configuration  Item  (CSCI)  -  a  software  application  or  a  major  compcment 
thereof. 

Computer  Software  Component  (CSQ  -  a  top  level  functional  module  within  a  computer  software 
oxifiguration  item  (CSCD>  CSC’s  are  generally  considered  to  be  one  structural  level  below 
theCSCL 

Computer  Software  Unit  (CSU)  -  low  level  software  modules,  usually  at  the  ftmction  or 
subroutine  level  that  perform  specific  functions  within  a  CSC. 

Data  Administration  Module  (DAM)  -  the  MDMS  module  responsible  for  MDB A  security  and 
administrative  maintenance  ftmctions. 

Data  Mana^mant  Module  (DMM)  -  the  MDMS  module  responsible  for  database  access. 

Gn^cal  User  Interface  (GUI)  -  the  MDMS  module  resptmsible  for  interfacing  with  the  user  and 
controlling  tl^  grs^ical  and  display  functionality  of  the  MDMS. 

Widget  -  “...  a  grs^diic  device  capable  of  receiving  input  from  the  keyboard  and  the  mouse  and 

communicating  with  an  2^plicati<Mi  or  an<^er  widget  by  means  of  a  callback.  Every  widget 
is  a  member  of  only  one  class  and  always  has  a  window  associated  with  it”  (from: 
OSF/Motif  Programmer’s  Guide,  Rev.  1.1,  Open  Software  Foundation,  Prentice  Hall, 
Englewood  Qiffs,  NJ,  1991,  p.  GL-13.) 
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APilNMX  B.  LBTT  OF  ACRONYMS 

ANP?  -  Amefktti  Natjonal  Standaids  bistitule 
CAST  -  Center  for  Air  Sea  TediiKdogy 
CSC  -  Comiwter  Software  Con^xxient 

-  Coaster  Software  Configuiatioo  Item 
CSU  >  Computo'  Software  Unit 
DAM  -  Data  Administratk»  j^xhile 
-  Database  Design  Requiremait 
raiR  -  Database  FUncBonal  Requirement 
DMM  -  Data  Managionent  Nfodule 
DCX>  -  Dqnitment  of  Di^ense 
OUI  -  Gr4>hical  User  Interface 
SMEAS  -  bueiactive  Data  Editing  and  Analysis  System 
MDBA  -  Ik^X)DS  Database  Administiatm' 

MDMS  -MOODS  Data  Mtaiagonent  System 

MDR  -  MDMS  Design  Requirement 

MFR  -  MDMS  RmcBonal  Requirement 

MKXX)S  -  Master  Oceanographic  Observation  Data  Set 

MSU  -  Mississii^  State  University 

NASA  -  Nation^  Aennautics  and  Space  AdministratiQn 

NAVOCEANO  -  Naval  OceanogRq)hic  OfiBce 

NEONS  -  Navy  Envixonmoital  Opmational  Nowcast  System 

OSF  -  C^ien  Software  Foundatitm 

RDBMS  -  Relational  Database  Managemrat  System 

SQL  -  Stnictured  Query  Language 
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APPENDIX  C.  THE  MOODS  RELATIONAL  DATABASE  MANAGEMENT 
SYSTEM  (RDBMS)  SPECIFICATION 


The  MDMS  accesses  the  MOODS  RDBMS,  a  modified  NEONS  database  created  specifically  to 
suf^rt  the  CSCI.  The  MOODS  database  exists  as  a  dedicated  e;  temal  and  independent  element  of 
the  system,  accessible  via  embedded  SQL  queries  to  the  underlying  RDBMS  engine.  The  MDMS 
queries  the  database  and  retrieves  requested  data  from  it  by  calling  NEONS  software  library 
functions.  NEONS  provides  a  data  model  for  all  generic  diata  types  (grid,  volume, 
latitude/longitude/time  (LLT),  line,  image  and  geographical);  however,  the  MDMS  only  uses  a 
modified  version  of  the  latitude/longitude/time  data  type  to  store  MOODS  profiles,  plus  the 
geographical  data  type  which  stores  coastlines  and  ocean  bathymetry  datasets.  MOODS  profile 
datasets  can  be  retrieved  by  the  following  parameters: 

latitude,  longitude,  date/time,  month,  water  depth,  parameter,  source  code,  instrument, 

classification  code,  and  cruise  identification  number. 

These  parameters  represent  an  enhancement  of  NEONS  capability  to  meet  MDMS  requirements. 
The  NEONS  latitude/longitude/time  data  type  allows  queries  only  by  latitude,  longitude  and 
date/time.  The  additional  parameters  (month,  water  depth,  parameter,  source  code,  instrument, 
classification  code,  and  cruise  identification  number)  were  moved  from  the  RDBMS  binary  large 
object  storage  format  to  allow  faster  dataset  specification  and  retrieval.  The  MDMS-specific  version 
of  the  LLT  data  type  is  referred  to  as  “LLTN_7”  because  of  the  seven  additional  query  parameters. 
The  MDMS  version  of  NEONS  also  incorporates  special  relational  tables  to  support  security 
classification  codes  and  a  MOODS  transaction  log. 

Further  information  about  NEONS,  its  structure  and  use  is  available  in  the  NEONS  design 
document  [“Database  Design  Document  for  the  Naval  Environmental  Operational  Nowcast 
System”,  Version  3.5,  Naval  Research  Laboratory  (NRL),  Monterey,  CA  93943-5006].  In 
addition,  the  NEONS  installation  package  includes  source  code  and  manual  pages  for  each  major 
functional  element.  NEONS  version  control  is  managed  by  the  Naval  Research  Laboratory, 
Monterey,  CA. 
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APPENDIX  D.  FUNCTIONAL  AND  DESIGN  REQUIREMENTS  FOR  THE 
MOODS  RELATIONAL  DATABASE  MANAGEMENT  SYSTEM  (RDBMS) 

DATABASE  FUNCTIONAL  REQUIREMENTS  (DBFR): 

DBFRl:  Database  must  be  capable  of  data  retrieval. 

DBFR2:  Data  ingestiKXi  into  die  rdbms  is  to  be  accomplished  either  internally  or  externally  to  the 
MDMS. 

DBFR3:  The  searchable  database  attributes  must  mclude  month,  water  depth,  parameter,  source 
code,  instrument  type,  classification  and  cruise  identification  number. 

DATABASE  DESIGN  REQUIREMENTS  (DBDR): 

DBDRl:  RDBMS  engine  is  Empress. 

DBDR2:  RDBMS  model  is  the  Naval  Environmental  Operational  Nowcast  System  (NEONS) 
Versitm  3.5.1. 

DBDR3:  Database  must  be  compatible  with  NAVOCEANO  Program  Modernization  Initiative 
(PMI). 
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APPENDIX  E.  THE  MDMS  DEVELOPMENT  ENVIRONMENT 


The  MDMS  has  been  (teveloped  in  a  Sun  Microsystems  SparcStation  model  10  computer  hardware 
environment.  The  operating  system  was  SUNOS  version  4.1.3,  including  the  resident  SUN  C 
compiler  which  was  used  to  write  die  MDMS  software  code.  Some  minor  elements  of  NEONS 
have  been  written  in  FORTRAN??  (Sun  FORTRAN??  version  1.4).  Graphics  support  is  provided 
by  UNIRAS  a^X  Toolmaster  version  6v3b.  The  RDBMS  engine  is  Empress  version  6.2.  The 
windowing  environment  consists  of  X-Windows  version  XI 1  R5  and  the  OSF  Motif  widget  set 
version  1.3. 


APPENDIX  F.  MOODS  STRUCTURES 

A  C  stnicture  is  a  collecti(Hi  of  data  variables,  pointers  or  odier  structures  grouped  together  for  the 
ctmvenience  of  using  a  single  variable  name  to  reference  or  idratify  die  whole  group.  The  use  and 
behavior  of  structures  is  covered  in  any  credible  C  programming  language  tutorial  oc  textbook. 

1.  The  NAVO  Structure  -  comprises  the  critical  data  framework  of  the  MDMS  application. 
The  NAVO  structure  and  its  internal  structures  are  defm^  as  follows: 

typedef  struct  { 

STATUS_BOARD_WIDGETS  ♦status_board_widgets; 

QUERY_VAL  ♦query_val; 

TTMEJLOC  *LocTime; 

Widget  region,  globe_map; 

char  seq_type[311; 

char  vrsn_name[31]; 

char  defaultsFile[120]; 

}  NAVO; 

Structures  Internal  to  the  NAVO  Structure 
typedef  struct  < 

Widget  lat_min_text,  lat_max_text; 

Widget  lon_niin_text,  lon_max_text; 

Widget  time_min_text,  time_maxjtext; 

Wid^t  class_min_text,  ciass_max_text; 

Wi^t  m<Mith_roin_text,  month_ihax_text; 

Widget  parm_min_text,  parm_maxjtext; 

Widget  cruise_mm_text,  cruise_max_text; 

Widget  inst_min_text,  inst_max_text; 

Widget  source_min_text,  source_max_text; 

Widget  load_min_text,  load_max_text; 

Widget  min_toggle,  max_to^le; 

}  STATUS_BOARD_WIDGETS; 

typedef  struct  { 

double  lat_min_val,  lat_max_val; 
double  lon_niin_val,  lon_max_vaI; 

DATE  tiine_min_val,  time_max_val; 
int  hour_min_val,  hour_max_val; 
int  mnt_min_val,  mnt_raax_val; 
int  sec_min_val,  sec_max_val; 
long  class_min_val,  class_max_val; 
long  month_min_val,  m(mth_max_val; 

ICMig  parm_min_val,  parm_max_val; 
long  cruise_min_val,  cruise_max_val; 
long  inst_min_val,  inst_max_val; 
long  source_min_val,  source_max_val; 
long  load_min_val,  load_max_val; 

Boolean  selectirxi.tj^; 

}QUERY_VAL; 
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typedef  struct  { 


DATE 

startjdate; 

DATE 

endjdate; 

douUe 

min^lat; 

double 

min.lon; 

douMe 

max.lat; 

double 

max.ltm; 

int 

startjiour; 

int 

aid_hour; 

int 

start.min; 

int 

eiKLmin; 

int 

statt_sec; 

int 

okI  sec; 

}  TIME_LOC; 

Note:  The  Widget  structure  is  proprietary  to  Ae  XLib/MOTEP  libraries. 

2.  The  NAVO  DATE  Structure  -  deHnes  the  elements  vriiich  comprise  date  and  time  within 
theMDMS. 

typedef  struct  { 
inthour; 
intmin; 
intday; 
int  month; 
intyear, 

>NAVO_DATE; 

3.  The  DISTRIBUTION  Structure  -  groups  all  variables  required  to  plot  a  histogram  or 
accumulatirn  chart 

typedef  struct  { 

£k>at 
float 
int 
int 

Boolean 
char 
diar 
char 
int 
int 
int  , 

Bodean 
BotAean 
Bocdean 
Pixn^ 

XWin^w Attributes  pix.at;  f*  Stcxe  dimensions  of  Pixmiq)  *f 
XWindowAttributes  hist_pa_at;  /*  Smre  dimmsitHis  of  Pixniap  *! 
XWindowAttributes  accLfu.at;  /*  Stme  dimensions  of  Pixmap  */ 


lat_deg;  /*  latitude  interval  */ 

lon.deg;  /* kmgitiKJe  interval*/ 

Ion  Jrinsize;  /*  longitude  cell  count  */ 

laLbinsize;  /*  ladhide  cell  count  */ 
grid;  /*  To  indicate  if  grid  is  needed  */ 

coast_type[151;  /♦  Skm,  8km,  20km  ♦/ 
tittel[50];  /*  Plot  type  title  ♦/ 
title2[S0];  /*  User-suf^jlied  title  ♦/ 

<*^_type;  /*  SaeCT/window  ♦/ 

[Aotjtype;  /*  not(Histogram/Accumulatk)n  */ 

rec.num;  /♦  Num  of  Read  */ 

tiieteisaaoc4^*  Indicates  presrace  of  Pixmap  */ 
ttieteisahisti^x;/*  Indicates  ptesatct  of  Pixmap  */ 
ttmdsapix;  /*  Indicates  ptesoice  of  Pixmr^*/ 

pixmap;  /*  Pixmap  to  store  gta{Aics*/ 
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nxmap  hisi;_puinap;  /*Pixmapta Histogram*/ 

Kxttop  accl_pixinap;  /*Pbuiii^  to  Accumulation  i^ot*/ 

float  pix_width;  /*  Size  of  Display  Pixel  */ 

float  ♦hist_aitay;  /*  To  keep  count  in  cdls  ♦/ 

Boolean  dataseL-Sdectedy*  Avoid  leselecting  data  for  Hist*/ 

Widg^  coast_text;  /*  Indicate  dioice  Made  */ 

NAVO  ♦moods_struct;  /♦  Global  Stmctuie  */ 

Window  accLwindow;  /*  Window  ID  */ 

Winctow  hist_window;  /*  Window  ID  ♦/ 

^^^ndow  plcrt_window;  /*  window  ID  */ 

}  DISTRIBUTION; 

4.  The  PARMVSDEPTH  Structure  -  groups  all  variables  required  to  plot  a  parameter  vs. 

depth  chart 

typedef  struct  { 

float  niin_x;  /*  Min  x-axis  value  ♦/ 

float  max_x;  /*  Max  x-axis  value  */ 

flotu  niin_y;  /*  Min  y-axis  value  ♦/ 

float  max _y;  /*  Max  y-axis  value  */ 

char  title[SO];  /*  graph  title  */ 
float  ♦*depdi;  /*dei^  Values  */ 

float  **data_array;  /‘Devalues  */ 

int  *piof_points;  /*  Points  Per  Profile  */ 

int  ptev_max_count;  /*  Maximum  profiles  */ 

int  max.count;  /*  Maximum  profiles  */ 

int  parmjtype;  /*  Parameter  type  */ 

int  total_obs;  /*  Total  Rees  */ 

NAVO  *moods_struct;  /*  Global  Structure  ♦/ 

Boolean  theieisacomppix;/*  Boolean  Flag  */ 

Boolean  dsnaset_selectedy*  Boolean  Flag  *! 

Pixmap  comp_pixmap;/*Pixmap  */ 

Window  window;  /*  Window  ID  */ 

int  devjtype;  /♦  Screen/window  */ 

}  PARMVSDEPTH; 

5.  The  LOGSTRUCT  Structure  -  groups  the  necessary  variables  to  output  a  portion  of  the 

MDMS  transaction  log. 

typedef  struct  { 

int  logjype; 

Widget  list; 

Widget  to_scieen; 

Wk^tto_file; 

Wi(^to_printer, 

Widg^namejext; 

Wk^  min_date_text; 

Widg^  max_(fctte_text; 

Widget  msgjtext; 
char  userName[20]; 

DATE  min_dale; 
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DATE  maiuctatB; 
toDg  func  Jd; 
kng  iiiiii,_^iiic.id; 
kng  aux.jmcjd; 
char  fiknameCSO]; 

}LOGSTRUCT; 

6l  The  SMRYPAGE  Stroctore  -  groups  the  necessary  variables  to  output  a  summary  page. 

typedrf  struct  < 

float  minLlat; 
float  mmjoa: 
float  max Jat; 
float  maxjkm; 
struct  { 

intyr, 

intttt_yr_cnt; 

structf 

intmo; 

long  tdLmojcnt; 

}  moLtm[12]; 

>  yrJbm[MAXjCNT]; 

structf 

Irnig  src.code; 
longttl_src_cnt; 

}  src_Wn(MAX_CNTl; 

struct  < 

long  insccode; 
long  ttl_inst.cnt; 

}  mstjMn(MAX_CNTl; 

struct  { 

int  clasjcode; 
long  tQ_clas_cnt; 
longtd_q^_cnt; 
long  ttLdistjcnt; 
long  ttLdist_9ialjcnt; 

}  clas_bin[MAX_CLAS_CNT]; 

>  SMRY_PAGE; 

7.  The  IMPORTEXPORT  Structure  -  ctmtains  the  necessary  variables  to  impmt  or  export 
datafile. 

typedrfstrwx  { 

NAVO  *moods_struct;  /♦  Gltrtul  Structure  ♦/ 

char  fitenamefSO];  /*Rlename to suxe header*/ 

int  type;  /*  IMPORTEXPORT,  or  EXPORT.IDEAS  */ 

\ifidgetolE;  /♦  Ok^K^  ♦/ 

}]l&ORTEXPORT; 


AFPENDK  G.  THE  MDMS  DEFAULT  CONFIGURATION  FILE 


Default  values  for  parameters  appearing  within  the  “Selection  Status”  textboxes  of  the 
MDMS  main  di^lay  may  be  maintained  in  a  user-created  default  file.  The  uso*  nuy  specify  the  file 
containing  default  values  by  including  the  “-f”  flag,  followed  by  the  filename,  when  launching  the 
MDMS  (example;  moods  -f  myfile).  If  the  default  file  is  not  indicated  on  the  command  line,  the 
MDMS  will  look  for  the  file  iiioods.defaults  in  the  current  directory.  If  the  moods.defaults 
file  cannot  be  located,  parameter  boxes  within  the  “Selection  Status”  portion  of  the  main  display 
will  be  blank  at  startup.  The  format  for  a  default  file  is  as  foUows; 

Latitude  21.3  30.0 

Longitude  -121.0  -109.0 

Date/Hour  19621207:6:0:0  19931008:12:0:0 
Classification  1 100010  1 100010 


Month 

3 

3 

Parms 

2 

3 

Cfuise-Id 

300 

300 

Instrument 

25 

25 

source 

4 

4 

load-date 

19920616  19920616 

The  values  contained  in  a  default  file  are  ordered  in  a  top-to-bottom  sequence  according  to  their 
appearance  within  the  “Selection  Status”  portion  of  die  main  display.  The  format  is  free  form 
excqit  diat  labels  and  numerical  values  must  be  separated  by  at  least  one  space  and  each  labeled  line 
must  end  in  a  carriage  return.  For  each  labeled  category,  there  are  two  numerical  entries,  a 
minimum  and  maximum  value,  on  each  line.  The  first  numerical  entry  is  the  minimum  value.  The 
second  numerical  value  is  the  maximum  value. 
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